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REMARKS 

I. Initial Remarks 

Applicants thank the Examiner for withdrawing the previously raised Section 1 12 rejections 
of claims 1-20 and 25-32. Claims 1-20 and 25-32 remain pending, with claims 1,6, 11 and 16 
written in independent form. No claims are added, amended or canceled in this paper. For at least 
the following reasons, all claims are in condition for allowance. 

In the Office Action, claims 1-20 and 25-32 were rejected under 35 U.S.C. 102(e) as 
allegedly being anticipated by U.S. Pat. Pub. No. 2002/0184390 to Hasan Alkhatib ("Alkhatib"). 
Alkhatib is cited for the first time; thus the Office Action presents new grounds of rejection. 
Applicants respectfully traverse the rejections. 

In view of the following arguments, all claims are believed to be in condition for allowance 
over the references of record. Therefore, this response is believed to be a complete response to the 
Office Action. 1 Further, for any instances in which the Examiner took Official Notice in the Office 
Action, Applicants expressly do not acquiesce to the taking of Official Notice, and respectfully 
requests that the Examiner provide an affidavit to support the Official Notice taken in the next 
Office Action, as required by 37 CFR 1.104(d)(2) and MPEP § 2144.03. 

II. Claim Rejections - 35 U.S.C. $102 

MPEP § 2131 states that to anticipate a claim, the reference must teach every element of the 
claim. "A claim is anticipated only if each and every element as set forth in the claim is found, 
either expressly or inherently described, in a single prior art reference." Verdegaal Bros. v. Union 
Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). '"The identical 
invention must be shown in as complete detail as is contained in the . . .claim.' See Richardson v. 
Suzuki Motor Co., 868 F. 2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989)." As detailed in 
the subsections below, each and every element as set forth in the claims is not found in Alkhatib. 

1 As Applicants' remarks with respect to the Examiner's rejections are sufficient to overcome these rejections, 
Applicants' silence as to assertions by the Examiner in the Office Action or certain requirements that may be applicable 
to such rejections (e.g., whether a reference constitutes prior art, motivation to combine references, assertions as to 
dependent claims, etc.) is not a concession by Applicants that such assertions are accurate or such requirements have 
been met, and Applicants reserve the right to analyze and dispute such assertions/requirements in the future. 
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Therefore, for at least the following reasons, the Section 102(e) rejection of claims 1-20 and 25-32 
should be withdrawn and the claims allowed. 

A. Independent Claim 1 

Independent claim 1 was rejected under Section 102(e) as allegedly being anticipated by 
Alkhatib. However, Alkhatib fails to anticipate at least "a key exchanger configured to repeatedly 
derive a cipher key such that the resulting cipher key changes over time" and to "decrypt, according 
to a cipher algorithm keyed by the cipher key, the extracted packet header data to determine a 
restored address" as recited in the context of claim 1 . 

1. "« key exchanger configured to repeatedly derive a cipher key such that the 
resulting cipher key changes over time' 1 '' 

Independent claim 1 recites in part "a key exchanger configured to repeatedly derive a 
cipher key such that the resulting cipher key changes over time." In the Office Action, paragraph 67 
of Alkhatib was cited as allegedly disclosing these recitations. (Office Action, page 3.) While 
Alkhatib mentions "unencrypting," Alkhatib fails to anticipate "a key exchanger" at all, let alone "a 
key exchanger configured to repeatedly derive a cipher key such that the resulting cipher key 
changes over time" as recited in the context of claim 1 . 

Alkhatib discloses a "data unit" addressed to a global address of a "domain name router," 
where the "data unit" further includes a domain name indicative of a local address within the stub 
network to be the destination for the data unit, (e.g., Alkhatib, Abstract.) Alkhatib further discloses 
that "the Domain Name Router receives the data, extracts the destination's domain name from the 
data, translates that domain name to a local address in its stub network and sends the data to the 
destination." (Alkhatib, paragraphs 12 and 14.) In Alkhatib, the "extraction or identification can be 
by unencoding, decoding, decompressing, unencrypting, etc." (Alkhatib, paragraph 36.) 

Cited paragraph 67 is in reference to Figure 10 of Alkhatib, which discloses the steps 

"receive packet," "identify domain name," "translate," and "send data." As cited by the Examiner: 

FIG. 10 describes the steps performed by DNR 138 when it receives 
the IP packet from host 150. In step 502, DNR 138 receives the IP 
packet. In step 504, DNR 138 identifies the destination's domain name 
from the packet. Identifying the domain name could include looking 
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for the domain name in the header, data portion or other location in an 
IP packet, TCP segment, application data, etc. Identifying the domain 
name may include reading an ASCII string. Alternatively, if the 
domain names are compressed, encrypted, encoded, etc., then DNR 
148 would need to decode, decompress, unencrypt, etc. In step 506, 
DNR 138 translates the destination domain name to a local address 
and in step 508 the packet is routed to the destination with the local 
address. FIG. 1 1 describes one exemplar embodiment for performing 
the step of translating the destination domain name to a local address 
(step 506 of FIG. 10). Other suitable methods of translating a domain 
name can also be used. Translating a domain name can include less 
than all of the steps of FIG. 1 1. In step 512, DNR 138 looks up the 
domain name in a DNR table stored in its memory or other storage 
device. The DNR table includes domain names and corresponding 
local addresses. In one embodiment, the DNR table could also include 
Ethernet addresses .... 

(Alkhatib, paragraph 67.) Paragraph 67 continues on to discuss "multiple DNRs, forming a tree." 
(M.) 

Alkhatib states that "if the domain names are compressed, encrypted, encoded, etc., then 
DNR 148 would need to decode, decompress, unencrypt, etc." (Alkhatib, paragraph 67.) However, 
Alkhatib fails to disclose or suggest any details of any decode, decompress or unencrypt operations. 
Specifically, Alkhatib fails to disclose or suggest "a key exchanger configured to repeatedly derive a 
cipher key," let alone "a key exchanger configured to repeatedly derive a cipher key such that the 
resulting cipher key changes over time" as recited in the context of claim 1 . 

For at least these reasons, independent claim 1 and all claims that depend therefrom are 
patentable over Alkhatib. 

2. '"''decrypt, according to a cipher algorithm keyed by the cipher key ..." 

Independent claim 1 further recites in part to "decrypt, according to a cipher algorithm keyed 
by the cipher key, the extracted packet header data to determine a restored address" within the 
context of the claim. In the Office Action, the Examiner cited paragraphs 12, 14, 36, and 67 of 
Alkhatib as allegedly disclosing the recitations. (Office Action, pages 3-4.) 

As mentioned by the Examiner, "[the] Domain Name Router receives the data, extracts the 
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Destination's domain name from the data, translates that domain name to a local address in its stub 

network and sends the data to the destination." (Alkhatib, paragraph 12.) Moreover, Alkhatib 

further discloses "packaging at least a subset of data to be communicated to an entity on a network 

into a data unit," where: 

The data unit can be formed by receiving a first set of data and a 
domain name. A field (or other subset) is created, which includes a 
first set of information representing the domain name. The field is 
appended to the first set of data to create the data unit. The data unit is 
sent to the Domain Name Router. The data unit could be an IP packet, 
a TCP segment, or any other data unit suitable for use with the present 
invention as long as the domain name can be reliably extracted from 
the data . In one embodiment, the information used to represent the 
domain name could include an encrypted version of the domain name, 
an encoded version of the domain name, a compressed version of the 
domain name, etc. 

(Alkhatib, paragraphs 13-14; Emphasis added.) Also as mentioned by the Examiner, "extraction or 
identification can be by unencoding, decoding, decompressing, unencrypting, etc.," and "if the 
domain names are compressed, encrypted, encoded, etc., then DNR 148 would need to decode, 
decompress, unencrypt, etc." (Alkhatib, paragraphs 36 and 67.) 

While Alkhatib mentions generally that "DNR 148 would need to decode, decompress, 
unencrypt, etc.," Alkhatib fails disclose any details at all of these decode, decompress, or unencrypt 
operations. Specifically, Alkhatib fails to anticipate "a cipher algorithm keyed by the cipher key" at 
all, let alone to "decrypt, according to a cipher algorithm keyed by the cipher key, the extracted 
packet header data to determine a restored address" as recited within the context of the claim 1 . 

Moreover, Alkhatib further fails to anticipate to "decrypt, according to a cipher algorithm 
keyed by the cipher key, the extracted packet header data to determine a restored address" within 
the further context of "to repeatedly derive a cipher key such that the resulting cipher key changes 
over time" as recited in claim 1 . Rather, Alkhatib fails to teach or suggest any such "cipher key" 
and "cipher algorithm keyed by the cipher key," let alone to "decrypt, according to a cipher 
algorithm keyed by the cipher key, the extracted packet header data to determine a restored address" 
by way of such a derived "cipher key." 
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For at least these reasons, independent claim 1 and all claims that depend therefrom are 
patentable over Alkhatib. 

B. Independent Claims 6, 11 And 16 

Each of independent claims 1,6, 11, and 16 was rejected under Section 102(e) as allegedly 
being anticipated by Alkhatib. While claims 1,6, 11, and 16 are each of different scope, for at least 
reasons similar to those discussed above with regard to independent claim 1, independent claims 6, 
11, and 16 are patentable over Alkhatib. 

For example, as discussed above with regard to independent claim 1 , Alkhatib does not 
teach or suggest "to repeatedly derive a cipher key such that the resulting cipher key changes over 
time" and to "decrypt, according to a cipher algorithm keyed by the cipher key, the extracted packet 
header data to determine a restored address" as recited in the context of claim 1 . Independent 
claims 6, 1 1, and 16 each includes like recitations, although claim 6 recites "decrypting," claim 1 1 
recites "means for repeatedly deriving" and "means for decrypting," and claim 16 recites to 
"repeatedly derive." 

Accordingly, for at least similar reasons to those discussed above with regard to independent 
claim 1, independent claims 6, 1 1, and 16 and all claims that depend therefrom are patentable over 
Alkhatib. 

C. Dependent Claims 2-5, 7-10, 12-15 And 25-32 

Claims 2-5, 7-10, 12-15, and 25-32 are in condition for allowance at least because they 
depend from one of independent claims 1, 6, 1 1, or 16. Further, the dependent claims also recite 
independently patentable subject matter, representative examples of which are discussed below. 

1. Claim 25 

Claim 25 depends from independent claim 1 and recites in part "the host portion of the 
address having been translated without the network portion also being translated, and wherein said 
translator is configured to restore the host portion of the address without also restoring the network 
portion of the address." In the Office Action, the Examiner cited paragraph 67 of Alkhatib as 
allegedly disclosing the recitations, without explanation. (Office Action, page 5.) 
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Paragraph 67 of Alkhatib discloses in part that: 

FIG. 10 describes the steps performed by DNR 138 when it receives 
the IP packet from host 150. In step 502, DNR 138 receives the IP 
packet. In step 504, DNR 138 identifies the destination's domain 
name from the packet. Identifying the domain name could include 
looking for the domain name in the header, data portion or other 
location in an IP packet, TCP segment, application data, etc. 
Identifying the domain name may include reading an ASCII string. 
Alternatively, if the domain names are compressed, encrypted, 
encoded, etc., then DNR 148 would need to decode, decompress, 
unencrypt, etc. In step 506, DNR 138 translates the destination 
domain name to a local address and in step 508 the packet is routed to 
the destination with the local address. 

(Alkhatib, paragraph 67.) Alkhatib further discloses that "the global address for DNR 138 in the IP 

packet is replaced with the local address in the table" and "the checksum for the IP header is 

adjusted if necessary." (Alkhatib, paragraph 68.) Moreover, as cited earlier in the Office Action, 

paragraph 15 of Alkhatib states that: 

In one embodiment, the data unit sent to the Domain Name Router 
includes a global IP address for the Domain Name Router. After 
translating the domain name to a local address, the Domain Name 
Router will replace the global address for the Domain Name Router 
with the local address of the destination . The step of replacing the 
global address with the local address can include adjusting any 
appropriate checksums or any other necessary fields in the data unit. 

(Alkhatib, paragraph 15; Emphasis added.) Thus, Alkhatib specifically discloses to overwrite the 

entire destination address of the data unit. 

Because Alkhatib discloses to overwrite the entire destination address of the data unit with 
"the local address of the destination," Alkhatib accordingly replaces both the network portion of the 
destination address and also the host portion of the destination address. Thus, as Alkhatib replaces 
the entire destination address, Alkhatib fails to anticipate "wherein said translator is configured to 
restore the host portion of the address without also restoring the network portion of the address ." 
(Emphasis added.) For at least these reasons, claim 25 is separately patentable over Alkhatib. 
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2. Claims 27, 29 And 31 

Each of claims 27, 29, and 31 was rejected under Section 102(e) as allegedly being 
anticipated by Alkhatib. (Office Action, page 6.) As discussed above with regard to claim 25, 
Alkhatib does not teach or suggest "to restore the host portion of the address without also restoring 
the network portion of the address." Claims 27, 29, and 3 1 depend from different base claims, but 
each includes like recitation. Thus, while claims 25, 27, 29, and 31 are each of different scope, for at 
least reasons similar to those discussed above with regard to claim 25, claims 27, 29, and 31 are 
separately patentable over Alkhatib. 

III. CONCLUSION 

In view of the above remarks, the pending application is in condition for allowance. 
Reconsideration and allowance are respectfully requested. 

It is believed that any fees associated with the filing of this paper are identified in an 
accompanying transmittal. However, if any additional fees are required, they may be charged to 
Deposit Account No. 18-0013, under Order No. 65632-0534. To the extent necessary, a petition for 
extension of time under 37 C.F.R. § 1.136 is hereby made, the fee for which should be charged 
against the aforementioned account. 

Dated: September 15, 2010 Respectfully submitted, 

Electronic signature: /Isaac T. Slutsky/ 
Michael B. Stewart 
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